The -Depth 2 parameter in original code was supposed to handle both cases: modules with version subdirs and without.
Can you please give an example directory/module structure that was not handled correctly by old code?

When working in the winget-dsc repository, I often found myself doing something like:

$env:PSModulePath += ";C:\source\winget-dsc\resources\Microsoft.DotNet.Dsc"

# Call function
Get-DscResourcesModules
# Old code did not list out the module

Hope that sheds some light on it.

Can you please post an output of
Get-ChildItem -Recurse -Path C:\source\winget-dsc\resources\Microsoft.DotNet.Dsc | %{$_.FullName}
Thank you.

There you go:

I have added both. The left is the main branch, and the right is the current one in this pull request.

Thank you; in the right picture - what is the full path to NpmDsc.psd1 that is returned by Get-DSCResourceModules ?

Ok, I think I got what's happening.
The module discovery in PowerShell (and consequently DSC PS adapter) requires that all module files should be in the module directory; and $env:PSModulePath should point to the parent of that module directory.
In your case, the line should be:
$env:PSModulePath += ";C:\source\winget-dsc\resources"
rather than
$env:PSModulePath += ";C:\source\winget-dsc\resources\NpmDsc".
This should work with existing code. Please try it.

Thanks for the explanation, Andrew. I tried it in the past, and that works. But sometimes, I want only particular modules to be found, with the structure mentioned in this PR and in the test. What are your thoughts on those?

@Gijsreyn I think the problem is that this is contrary to how module discovery works with PS7 and it would be preferable to not deviate from that. Is this only for development purposes or do you have a real scenario where you want to limit the discovery?

I can understand, and this was the use case. Feel free to abandon the pull request. I appreciated the time you guys looked into it.

Hi @SteveL-MSFT. After testing for a while, I got a scenario that breaks the current testing cycle.

Imagine the following use case found while developing in winget-dsc. To test out both cases by either using Invoke-DscResource or the class directly, we declare at the top of the test the using module statement.

When modules are being discovered in the lower levels, so say C:\source\winget-dsc\resources\NpmDsc, it correctly loads the using module statement, but it doesn't do it for PSDesiredStateConfiguration. If I now add it on higher level in the same call, I get an error stating:

PS C:\Users\User> $env:PSModulePath += ";C:\source\winget-dsc\resources\Microsoft.Windows.Setting.Language"
PS C:\Users\User> Get-DscResource
Exception: Exception setting "Module": "Cannot convert the "System.Object[]" value of type "System.Object[]" to type
"System.Management.Automation.PSModuleInfo"."

I know you've closed down the ticket, but perhaps we can still consider it. Thanks.